え、そんなに！？意外と知らないAWSでお金がかかるポイント5選！！ JAWS DAYS 2020登壇資料 #jawsdays #jawsdays2020

深澤俊

2020.03.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは(U・ω・U)
AWS事業部の深澤です。

さて僕はこれまで次のようなブログを書いてきました。

全部で15ポイントもあるのですが、今までの中から厳選して5つの特に注意したいポイントをピックアップしオンライン開催されたJAWS DAYS 2020のランチセッションで登壇/発表してきました。

資料

Jaws days 20200322 from Shun Fukazawa

動画

解説

ポイント1：　通信費

AWSではわずかではありますが、通信を行うと課金が発生します。AWSから外への通信は$0.114（12.33円）/GB、リージョン間通信の場合は$0.09（9.74円）/GB、同一リージョンであっても異なるAZへの通信は$0.01/GB（1.08円）です。

こちらはEC2だけでなく他のサービスも含めたサービス間通信の合計であることに注意してください。ディザスタリカバリで複数リージョンに跨ったりログを他のリージョンに転送したりして意外と料金が上がりがちです。

対策

可用性をよく検討することが大切です。よく考えてみると複数リージョンにまたがらなくても良いかなということもあるかと思います。また複数アベイラビリティゾーンにまたがる必要があるかというもの改めて検討してみていいかもしれません。一つのアベイラビリティゾーンに寄せるのも、地理的に近くなることから通信が早くなるというメリットがあります。

ポイント2：　DynamoDB

まずは基本のおさらいですが、キャパシティユニット（以下CU）と呼ばれる単位で料金を計算します。どのくらいCUを消費したかで料金は決まります。現在、読み込むデータ量と消費するキャパシティユニットの関係は次のようになっています。

読み込み（4KBにつき）
- 強力な整合性のある読み込み： 1CU
- 結果整合性のある読み込み：0.5CU
書き込み（1KBにつき）
- 標準の書き込み：1CU

※これにトランザクションを付けるかつけないかでも消費CUが変わってくるのですが、今回は割愛させてください。

このCUを従量課金で支払うか定額課金で支払うかでCU単位の料金が変わってきます。

オンデマンドキャパシティモード
- 従量課金。負荷に応じて柔軟にCUを割り当て。
プロビジョニング済みキャパシティモード
- 定額課金。事前に発生する負荷を予測しCUを割り当て。

※ 定額課金といいつつ、Cloudwatchと組み合わせることでAutoScaling対応にすることもできます。こちらについての詳しい解説は今回割愛させてください。情報が欲しい方は以下のリンクをどうぞ。

ではDynamoDBで料金が発生しがちなポイントをみていきましょう。

強力な整合性のある読み込み

まずご紹介したいのは強力な整合性のある読み込みです。

DynamoDBではデータを複数のアベイラビリティゾーンに書き込むことによって可用性を担保しています。データを書き込んだ際に全てのアベイラビリティゾーンにデータが書き込まれる前にDynamoDBは書き込み完了と返します。そのため書き込んだ直後に読み込みを行うと結果が反映されてないことがあります。ここで強力な整合性のある読み込みを行うと確実に書き込んだデータを読み取り可能なのですが、結果整合性のある読み込みと比較し2倍のCUを消費します。DynamoDBでは読み込み負荷が高くなった（CUの消費が高くなった）場合にはDAXと呼ばれるキャッシュ機能を用いることで改善可能なことがあるのですが、こちらは強力な整合性のある読み込みの場合は使用できません。

対策

DynamoDBは基本的に結果整合性のある読み込みで設計しましょう。一度、強力な整合性のある読み込みで全体を設計してしまうと戻すのは困難です。結果整合性のある読み込みであれば、将来的に先ほど紹介したDAXの利用も可能です。まずは結果整合性のある読み込みで提供したいプロダクトを提供できないかを検討しましょう。もしくはプロビジョニング済みキャパシティモードにして必要最低限のCUだけ付与も有効ですが、この場合は最悪アプリケーションの性能が頭打ちになる点に注意が必要です。CUの消費量増加を検知するという観点から、ConsumedReadCapacityUnitsを監視するのも有効なので是非監視しましょう。

GSIに対する書き込み

GSI（グローバル・セカンダリ・インデックスの略）とは、当初定義したプライマリキー以外のAttributeで検索を行いたい場合に定義可能なインデックスです。テーブルを作成してしまった後でも定義可能で、上限（1テーブルあたり 20個）はあるものの上限緩和申請も可能で大変便利なのですが使いすぎには要注意です。読み込み処理の場合、その対象となるインデックスやテーブルだけにCUが使われますが、書き込み処理を行った場合その結果がインデックスにも反映されるためテーブル及び全てのインデックスにおいてCUが発生します。

対策

やはりまずは必要最低限のGSI数にできるようテーブル設計の段階から気をつける（GSIの利用は最低限にする）というが大切です。もちろん、プロダクトに影響が出ないことが大前提ですが。また、強力な整合性のある読み込みと同じように書き込みで消費したCU数を監視できるメトリクス（ConsumedWriteCapacityUnits）があるのでCU異常消費を検知するという観点で大変有効です。

番外編

ちなみに意外と知られてませんが、コンソール画面でテーブルの内容を確認しただけでも読み込みの項目をクリックしただけでもRCUを消費します。

「あれ、そういえばテーブルってどんな感じになってたっけな〜」と軽い気持ちでクリックするとユニット数分のお金が溶けて、最悪RCUが不足している場合にはサービスに影響が出るので注意しましょう。

ポイント3：　AWS PrivateLink

まずVPCエンドポイントには2種類あるということを最初に整理しましょう。ゲートウェイエンドポイントはルートテーブルを編集してターゲットとして使用するタイプのエンドポイントになります。対応しているのはS3とDynamoDBのみですが利用料金は掛からないお得なサービスです。一方で今回取り扱うインターフェイスエンドポイントはサービスを宛先とするエンドポイントになります。エンドポイントはENI（Elastic Network Interface）を持ち、設定したサブネットのIPアドレス範囲のプライベートIPアドレスを持ちます。

今回取り扱うインターフェイスエンドポイント（AWS PrivateLink）は有料となっており次のような料金が発生します。

各AZのVPCエンドポイント1つあたりの料金 (USD/時間)	処理データ1GBあたりの料金 (USD)
0.014USD	0.01USD

ミソなのは1つ辺り時間単位で課金されていくことにあります。例えばAWS Systems Managerというサービスがあるのですが、こちらをAWS PrivateLinkで使うことになった場合には以下のエンドポイントを設定しなくてはなりません。

com.amazonaws.リージョン.ssm
com.amazonaws.リージョン.ec2messages

これに加えてSystems Managerを使用してVSS対応のスナップショットを作成する場合には以下のエンドポイントも必要になります。

com.amazonaws.リージョン.ec2

さらにさらにSession Managerを使用してインスタンスに接続する場合には以下のエンドポイントも必要になります。

com.amazonaws.リージョン.ssmmessages

これらを全て使用したとすると1ヶ月（30日）合計で40.32USD（4432.84円）がかかります。これに加えて通信量が上乗せされます。さらに他のサービスのAWS PrivateLinkも…となると意外と月額の料金が大きくなってしまいがちです。

対策

必ずしもVPC内部からの通信でなければならないケースもそんなに多くないと思うので、通常通りネットワーク経由での通信も検討されて良いかと思います。例えば先ほどのAWS Systems Managerですが、Private Subnetのインスタンスを対象とする場合にはNatGateway経由でも通信が可能です。確かにVPCの外側を通信することになってしまうのですが、IAMロールで権限制御していますし通信はSSLで暗号化されているので全くセキュリティ対策ができていないわけではありません。ちなみにNatGatewayは先日同じシリーズで取り上げさせていただいた料金注意なサービス（前回の調査結果だと1台辺り1ヶ月44.64USD）なのですが、他のAWS PrivateLink節約及びインスタンスのアウトバウンド通信を確保してくれると考えれば、決して損なサービスではないと思います。

ポイント4：　CloudWatch logs

発表当時、CloudWatch logsでは次のような料金設定となっていました。（本ブログ執筆時も変わっていないことを確認済みです）

注目すべきはデータの取り込みにかかる料金です。これはCloudWatch logsに送ったログのデータ量が課金対象となります。仮に1時間で30GBほどログを出力するアプリがあったとすると、1時間毎に22.8USD（2530.02円）が溶けていく計算となってしまいます。

対策

ログの要件をよく検討しましょう。必ずしもCloudWatch Logsですぐに可視化したり検索したりしたいログばかりではないかと思います。そういったログについてはFluentd（Fluent Bit）を利用したりして一旦S3に集約しておくのも有効です。保存や転送だけならS3の方がコストを低く抑えられますし分析を行いたい場合には別途AthenaやAWS Glueを用いるという選択肢もあります。

ポイント5：　Elastic IP アドレス

Elastic IP アドレス（以降、EIP）についてインスタンスにアタッチ（関連付け）していなければ課金が発生するというざっくり理解の方もいらっしゃるのではないでしょうか。実はEIPの課金はもう少し複雑で逆に課金が発生しないパターンは1つしかありません。それは「稼働しているインスタンスにアタッチされており、かつそのインスタンスにはEIPが1つしかアタッチされていない場合にEIPは無料」です。

またインスタンスに関連付いているEIPを外して他のインスタンスに関連付ける行為を「リマップ」と呼びますが、こちらは100回までは無料、その後1回でも超えると課金が発生します。その額1回につき0.1USDと結構高めなので要注意です。

EIPはEC2インスタンスだけではなくNatGatewayでも使います。以下のスライドにあるようにNatGatewayでは削除した際に、EC2インスタンスのように関連付いているEIPを解放するか聞いてくれません（発表当時）。このことからNatGatewayに付いていたEIPについては解放を忘れてしまいがちです。

対策

対策ですが、AWS Configのマネージドルールであるeip-attachedを導入することを推奨します。

こちらを導入しAWS Configからの通知で空いているEIPの検知が楽になります。上記ドキュメントにも書かれていますが評価の結果が出るまでは最大 6 時間かかることがあるのでその点だけ注意です。
リマップについては極力回数を控えるようにしましょう。

なおEIPの話は弊社の渡辺聖剛の記事が非常に参考になります。是非併せてご一読をいただければと思います。

最後に

いかがでしたでしょうか！オンライン登壇は僕自身初めての試みでリアクションが少ない中での発表はいつもより緊張したしいい経験になりました。また毎回のサービス選定は皆様からいただいているはてブやTwitterのご感想やリクエストを参考にさせていただいている部分もかなり大きいです。また今回も様々なご意見いただけると幸いです。

※ JAWS Days運用チームの皆様には、撮影中リアクションをいただき大変ありがたかったです。この場をお借りし御礼申し上げますm(_ _)m

また、請求が来てから気づくのではなく、監視しておいて早めに異変を検知できるようにしておきたいですよね！いくつか参考になりそうな弊社ブログをピックアップしましたので良かったら参考にしてみて下さいm(_ _)m
AWSサービス毎の請求額を毎日Slackに通知してみた
 支払アカウントからリンクアカウントのBilling Alertを設定する

以上、深澤（@shun_quartet）でした！